Jaderné noviny 284 - II

1. 12. 2004 | Robert Krátký | Jaderné noviny | 4043×

Linux 2.6.10-rc1: 'Opilý mravenečník'; způsob číslování verzí. Linux 2.6.9-ac5. Automatické kontrolování správnosti. Správa man-pages.

Do konference přišlo celkem 2980 emailů, nejvíce jich poslali Adrian Bunk, Ingo Molnar a Linus Torvalds.

Linux 2.6.10-rc1: 'Opilý mravenečník'; způsob číslování verzí, 103 e-mailů

22. říj - 29. říj

Linus Torvalds oznámil 2.6.10-rc1:

Přemýšlení o názvu této verze bylo dlouhé a pracné (neboli: dal jsem si pivo a koukal na televizi... a koblihy) - protože jedním z hlavních problémů u verze 2.6.9 byl právě způsob pojmenování.

Měla by být "-rc1"? nebo "-pre1", aby bylo patrné, že ještě není dostatečně dobrá k vydání? Nebo bych to měl udělat jako kosmonauti a odpočítávat dolů místo nahoru? Nebo snad pojmenovat podle dne v týdnu, kdy verze vyšla? Otázky, otázky...

Jenže mi to přijde zbytečné. Prostě to pojmenuji "-rcX", protože (zcela zjevně) nemám tušení, kde je ta hranice mezi "pre" a "rc", nebo (ještě zřetelnější) kdy se z toho stane další finální verze.

Takže abych svůj ubohý mozek nepřetížil, budu jim všem říkat -rc vydání. A budu doufat, že to vývojáři pochopí jako znamení, že byly začleněny nové věci a je potřeba zpomalit a postarat se o to, aby byly zařazené patche dostatečně brzy stabilizovány.

Bez dalších okolků tedy oznamuji 2.6.10-rc1.

Jo, a to _skutečné_ jméno se změnilo. Už to není Sťatý klokan, to je hrozně včerejší. Teď máme Opilého mravenečníka! Posílejte objednávky!

Několik vývojářů se vyjádřilo, že dávat nejdříve 'pre' a až potom 'rc' má smysl, protože 'rc' je zkratkou pro 'release candidate'. Matt Mackall napsal: Ta hranice se pozná podle toho, že už máš cukání to přejmenovat na 2.6.další. Pokud neplánuješ (nebo nemůžeš) přejmenovat 2.6.x-rc1 na 2.6.x, není to "release candidate" Con Kolivas s tím souhlasil, ale dodal: Mám takový pocit, že Linus si z nás utahuje, když tu s námi tyhle věci probírá. William Lee Irwin II připojil, že se mu celá ta diskuze zdá zbytečná, a že Linus má dost starostí s jinými věcmi, než aby si měl ještě dělat hlavu s tímhle. A na to Linus odpověděl:

Pánové, klid. Myslel jsem "boje o jméno" v tom praštěném slova smyslu, ne v tom ošklivém.

Skutečnost je taková, že názvy Linuxu stály vždycky za houby. No, přinejmenším ta čísla verzí, která jsem používal. Jiní lidé bývají trochu organizovanější. Já jsem takový ten "umělecký" typ, takže občas udělám něco nového, zákonitě přiblblého.

Zatím nejlepší možností bylo použít prostě další číslo, což dává smysl vzhledem k mé averzi k -rc i -pre.

Jenže se mi čtyři čísla na pohled nějak nelíbí, takže je mi to vlastně jedno. Budu používat "-rc" a bude to znamenat "raplá cifra".

A co je důležitější, mohli bychom si všichni uvědomit, že na tom zase tak moc nezáleží ;).

Nick Piggin napsal:

Linusi, souhlasím, že to není nic tak důležitého. Pro mě je hlavní, že _skutečné_ release candidate verze bych mohl více vyzkoušet. Prohnat je více testy, ujistit se, že dobře běží na všech mých počítačích atd. Předpokládám, že by se to hodilo lidem s velkými sadami testů a také těm, kdo spravují "jiné" architektury.

Rozumím tomu, že vždycky se najde "jeden další" patch, který musí být začleněn, ale když teď provozujeme ten stabilně vývojový systém, nemohly by být nějaké dva nebo i tři týdny jen pro stabilizaci s jen opravdu nutnými opravami nic špatného.

Bill Davidsen odpověděl: Také se přikláním k tomu, že názvy pre a rc jsou dost výmluvné v tom smyslu, že u -pre by ještě mohlo být uvažováno o nových funkcích, kdežto u -rc už stojí za to provádět pořádné testování. Pokud se to takhle Linusovi nelíbí, asi by bylo fajn mít nějaký jiný způsob, jak to naznačit. A Linus odpověděl:

No, já se ve skutečnosti snažím v oznámeních do konference vysvětlovat, co se děje.

Jedním z důvodů, proč nemám rád "rcX" vs. "-preX" je to, že mají tak nejasný význam. Oproti tomu když patch popisuji, snažím se vysvětlit, co si myslím, že se změnilo. A pokud mám pocit, že jsme připraveni na finální vydání, řeknu něco jako

..

Ok,

snažím se to tak do týdne připravit pro finální 2.6.9, takže jej, prosím, pořádně otestujte. A pokud máte připravené patche, chvíli s nimi ještě počkejte, až bude venku 2.6.9. Bylo by fajn mít 2.6.9, který nebude okamžitě potřebovat malé opravné vydání ;).

....

což je podle mého názoru daleko výstižnější.

A to je jen další důvod, proč název sám o sobě nemá takový význam. Nikdy nemůže obsáhnout tolik informací, kolik by od něj lidi očekávali.

Linux 2.6.9-ac5, 8 e-mailů

29. říj - 31. říj

Alan Cox oznámil nové vydání svého vlastního patchsetu, 2.6.9-ac5: Obsahuje některé z těch menších oprav a zároveň opravuje nepříjemnou chybu v __init. Nic extra důležitého pro lidi, kteří nepoužívají S390 - pokud se nesetkávají s těmi popsanými chybami, nebo nepotřebují nové ovladače. Nuno Silva odpověděl: Díky bohu někdo začal spravovat stabilní jádro 2.6! Greg Louis souhlasil: Chtěl jsem počkat až na 2.6.10 -- potřebuji spolehlivý provoz a všechno to "tahle a tamta zásadní nová funkce zase nefunguje" mě odrazovalo -- ale Alanovi se dá věřit.

Automatické kontrolování správnosti, 4 e-maily

30. říj

Linus Torvalds napsal:

Právě jsem do jádra začlenil patche podporující automatické kontrolování správnosti, které jsem přidal ke sparse: počítání statických informací o "kontextu kódu".

Infrastruktura sparse je docela pružná a můžete počítat více méně cokoliv chcete. Ale je to navrženo tak, aby se testovalo, zda odpovídá kontext vstupu a výstupu, a že žádná cesta funkcí nikdy nezačíná s konfliktními kontexty.

Konkrétně je to navrženo pro dělání věcí jako je porovnávání "lock" s párovým "unlock". A teď je to i přesně to, co kód umí: každý spinlock v kontextu je počítán jako "+1", každý spinunlock je počítán jako "-1" - a nakonec by to mělo vycházet.

Pokaždé to samozřejmě nevyjde. Vzhledem k tomu, že jde o statický analyzátor, nelíbí se mu třeba následující kód:

        int fn(arg)
        {
                if (arg)
                        spin_lock(lock);
                ...
                if (arg)
                        spin_unlock(lock);
        }

protože ten kód není staticky deterministický a věci mezi tím mohou být volány s i bez drženého lock. Ale už dlouho není něco podobného vítané a není moc případů, kde by se to stávalo.

Zatím je počítání zapnuté jen když používáte sparse a ručně na příkazovou řádku přidáte parametr "-Wcontext" Spinlocky byly popsané pouze pro SMP, takže to bude fungovat pouze s CONFIG_SMP. To jsou drobnosti...

A protože sparse provádí čistě lokální rozhodnutí, musíte sparse říct, pokud doopravdy hodláte v jedné funkci podržet lock a pustit ho v jiné. Popis musí být v deklaraci funkce, která lock bere (pomocí "__acquires(lockname)") a ve funkci, která jej pouští (pomocí - překvapení - "__releases(lockname)"). To sparse uvědomí o tom, že má odpovídajícím způsobem aktualizovat kontext ve voláních, ale zároveň se tak sparse dozví, jaký má očekávat vstupní/výstupní kontext u těch popsaných funkcí.

Zatím jsem žádné z funkcí nepopsal, tak očekávejte varování. Když spustíte kontrolu, budou varování vypadat nějak takto:

    CHECK   kernel/resource.c
  kernel/resource.c:59:13: warning: context imbalance in 'r_start' - wrong count at exit
  kernel/resource.c:69:13: warning: context imbalance in 'r_stop' - unexpected unlock

což prostě znamená, že "r_start" získala lock a "r_stop" jej pustila a sparse o tom nevěděl. Tento případ je jasný a stejně tak i popisy.

Komplikovanější je:

    CHECK kernel/sys.c
  kernel/sys.c:465:2: warning: context imbalance in 'sys_reboot' - different lock contexts for basic block

kde varování "different lock contexts" znamená, že sparse zjistil, že kód v té funkci je dosažitelný ze dvou různých lock kontextů. Takový případ je vlastně neškodný, protože se stane jen to, že po restartu stroje bude kód nedosažitelný a sparse tomu nerozumí.

Ale v jiných případech je to závažnější a nerovnováha locků je způsobena dynamickými daty, kterým sparse nemůže rozumět. V takovém případě může být varování ručně zakázáno, ale nezdá se, že by podobných případů bylo moc. Kompletní build kernelu má u mě asi 200 varování, z nichž většina jsou ta neškodná (tj. toho druhu, kdy jedna funkce lock získá, druhá jej pustí, ale nebyly řádně popsány).

sparse by mohl být rozšířen na jakýkoliv kontext, kde jde o párování, a já o tom chtěl lidem říct pro případ, že by je to zajímalo.

Greg KH řekl Linusovi: Pěkné, moc se mi to líbí. Už to objevilo pár chyb v USB ovladačích.

Správa man-pages, 2 e-maily

31. říj

Po té, co spravoval man-pages 9 let, řekl Andries Brouwer: Právě jsem vydal man-pages-1.70. Najdete na obvyklých místech. Kvůli stále se zvyšujícím časovým nárokům a pokračujícímu RSI [Repetitive Strain Injury] se pro mě spravování man-pages stalo přiliš složité. Naštěstí Michael Kerrisk souhlasil s tím, že správcovství převezme. Opravy a doplnění posílejte na mtk-manpages@gmx.net.

---

V originálu Kernel Traffic 284 vyšla navíc ještě tato témata:

• Better SMP Process Migration
• Linux 2.4.28-rc1; Straggling Patches Considered For Inclusion
• Different Perspectives On The Status Of Real-Time
• New Virtual cputime For Micro-Second Accounting
• Some Discussion Of Binary Firmware
• Cross-Compilation HOWTO
• Kprobes Updates
• Linux 2.6.10-rc1-mm2 Released
• Migration To New Argument-Passing Method For Some Assembly Interfaces

Tento článek vychází ze seriálu Kernel Traffic (www.kerneltraffic.org) a je zveřejněn pod licencí GPL verze 2.        

Komentáře

[Dworkin]

Pivo a koblihy...no potes koste

[David Jež]

Proc? Idealni kombinace, ne ? Jinak jsou i lepsi... BTW doporucuji precist knizku ,,Jak poznate, ze uz jste ve Finsku prilis dlouho`` od Lenky Pazderove a zvlaste pasaz o jidle. Akorat to chce mekkou podlahu, az se na ni budes valet smichy.
-djz

[Martin Kratochvil]

Ten preklad "rapla cifra" zni mazane, jaky byl ale original ?

Diky

[Luke]

V originále je: Ridiculous Count

[Jiří Svoboda]

LOL, ja si taky obcas hledam, jak znely nektere zajimave slovni obraty v originale. Autora prekladu s tim ale neotravuju.

[Robert Krátký]

Neberu to jako otravovani .